Modeling and Applying the Knowledge of Synthesizer Patch Programmers

concepts On top of this first layer of representation, we build up a hierarchy of concepts that represent the structural part of the programmer's expertise. As will be explained later, the concepts introduced here are used to define transformations. We divide these concepts into three categories: Abstract concepts built from fundamental concepts. These include partial descriptions of sounds, such as heldTimeFunction, defined as a TimeFunction whose 'sustainLevel' value is greater or equal to 1. In synthesis terms, this allows to describe, for instance, sounds whose loudness eventually stabilizes to a non-zero value. On the 05R/W, this is obtained by setting the Time Variant Amplifier Envelope Generator's Sustain Level to a strictly positive value.concepts built from fundamental concepts. These include partial descriptions of sounds, such as heldTimeFunction, defined as a TimeFunction whose 'sustainLevel' value is greater or equal to 1. In synthesis terms, this allows to describe, for instance, sounds whose loudness eventually stabilizes to a non-zero value. On the 05R/W, this is obtained by setting the Time Variant Amplifier Envelope Generator's Sustain Level to a strictly positive value. timeFunction and the (sustainLevel, ge(1)) => heldTimeFunction. Similarly, we introduce abstract concepts that, as will be seen below, play a part in building up the brassy-able sound type's representation. This code listing shows the manner in which these interdependent, abstract concepts are introduced. FilterEnveloppe and heldTimeFunction and the(attackTime, ge(17) and le(25)) and the(attackLevel, ge(85)) and the(decayTime, ge(60) and le(75)) and the(intermediateLevel, ge(25) and le(35)) and the(heldLevel, ge(25) and le(35)) => brassyAbleFilterEnv. filter and the(hasEnveloppe,brassyAbleFilterEnv) => brassyAbleFilter. brightTone and the(hasFilter, brassyAbleFilter) and the(hasAmp, brassyAbleAmp) => brassyAbleTone. voice and atleast (1, hasTone, brassyAbleTone) => brassyAbleVoice. Other examples of abstract concepts which reflect structural expert knowledge are those describing 'non transformable' sounds. Contrary to the above abstract concepts, these concepts provide complete descriptions of sounds which do not afford any particular transformation but which are used for describing transformable sounds: sound and no(hasVoice, voiceWithInharmonicTone) => harmonicSound Note that since any sound type is subsumed by the transformable sound type soundInGeneral, even instances of non transformable sounds types can undergo some general transformations, such as 'make bright' or 'make dull'. Concepts describing transformable sounds. Finally, these concepts describe the sounds types found in the hierarchy (figure 1). Here are a few examples of such concepts. harmonicSound and some (hasVoice, brassyAbleVoice) => brassyAbleSound sound and all(hasVoice, sustainAbleVoice) => sustainAbleVoice. sound => soundInGeneral. Concepts representing transformations themselves. To each sound type we associate a list of transformations, represented as mere character strings. This list is materialized by a sub-concept of possibleTransformations, an extensional concept which lists all possible transformations for all existing sound types. Here are a few examples: possibleTransformations:= attribute_domain ([warm, brassy, dull, decaying (...)]). affordsTransformation :< domain(sound) and range (possibleTransformations). brassyAbleSound :< affordsTransformation : brassy. WarmAndSharpAbleSound :< affordsTransformation: warm and sharp. 5. Integration scheme Representing sounds as objects, in the sense of objectoriented programming, is particularly natural in our context, where emphasis is put on transformations. Each transformation is represented by a Smalltalk method defined in class CurrentSound. The integration scheme needed to link these two representations is based on two principles: fundamental concepts on one hand are represented by Smalltalk classes. Each role of a concept is represented by an instance variable of the corresponding class. An actual sound is represented by an instance of class CurrentSound, and its parameters by instances of the corresponding classes. Transformations, on the other hand, are represented by methods associated to class CurrentSound. Each method modifies the current sound by changing some values of its parameters. Therefore, the semantics of the BACK symbol representing transformations is given by the corresponding Smalltalk method. This yields a twolevel representation framework with two links, as shown in Figure 2.